Specifying Reusable Security Requirements

Unlike typical functional requirements, security requirements can potentially be highly reusable, especially if specified as instances of reusable templates. In this column, I will discuss the concepts underlying security engineering including its quality subfactors. I will then address the issue of security requirements and how they differ from the architectural mechanisms that will fulfill them. Then, I will discuss the value of reusable parameterized templates for specifying security requirements and provide an example of such a template and its associated usage. Finally, I will outline an asset-based riskdriven analysis approach for determining the appropriate actual parameters to use when reusing such parameterized templates to specify security requirements. 1 CONCEPTS UNDERLYING SECURITY ENGINEERING To specify security requirements, it is critical to first understand the concepts underlying security engineering. And the most important concept of these is ‘security’ itself. Whereas security is often defined as an incomplete subset of its most important quality subfactors (e.g., integrity and privacy), the following figure illustrates that a more general and complete definition of security is that it is the degree to which malicious (i.e., unauthorized and intentional) harm to valuable system assets is prevented, reduced, and properly responded to. Thus, security is about protecting these assets (e.g., data, services, hardware, and personnel) from harm due to various kinds of attacks (e.g., password sniffing, spoofing, viruses) that may be mounted by the various kinds of attackers (e.g., hackers, crackers, disgruntled employees, international cyber-terrorists, industrial spies, governmental spies, foreign military, etc.). These assets are at risk due both to various kinds of threats (e.g., theft, vandalism, unauthorized disclosure, destruction, fraud, extortion, espionage, trespass, etc.) of attack as well as the vulnerabilities the system may 1 Some may argue that the term ‘malicious’ is too strong. What about people who vandalize the website of a company that pollutes the environment? What about someone who uses company computers to surf the Web in violation of company policy. The first example is a cybercrime and the second is an unauthorized use of property. In both cases, the victims would be justified to consider these acts malicious. If the term ‘malicious’ still seems too harsh, just consider it to mean the combination of unauthorized and intentional. SPECIFYING REUSABLE SECURITY REQUIREMENTS 62 JOURNAL OF OBJECT TECHNOLOGY VOL. 3, NO. 1 have. Security requirements are engineered to specify the system’s security policies and both policies and requirements should address these security risks. Security mechanisms (e.g., user IDs, passwords, encryption, firewalls, antivirus software, intrusion detection systems, etc.) are then architected to fulfill the security requirements. Some of these concepts influence the engineering of security requirements (e.g., policies, risks, threats, and assets), whereas others (e.g., security mechanisms, security vulnerabilities, and attacks) are influenced by the security requirements. Fig. 1: Concepts that Influence and are Influenced by Security Requirements The following list defines these security-oriented terms that will be used during the remainder of this column: